Securing your system with dialup passwords

By Al Alexander

As the world continues the trend toward remote and mobile computing, an ever-increasing concern is maintaining system security over dialup telephone lines. Once you attach a modem and a phone line to your computer, you expose your system to a variety of external threats.

I can recall one instance when a friend and I discovered a modem leading into our company's VAX mainframe computer. We were calling our VAX System Manager and accidentally dialed the last number of his phone number incorrectly. Suddenly we heard the familiar sound of a remote modem.

Curiosity got the better of us, and we reached over to a work-
station, used our modem to call the previous phone number, and found a login message from our company's VAX mainframe. Because it was against company policy to have modems attached to our mainframe, this was a startling discovery, which we kept to ourselves.

In this article, we'll explore the process of adding dialup passwords to your Solaris computer's modem lines. This process adds another layer of security to your incoming modem lines by forcing intruders to break an additional password to gain access to your computer system.

Overview

Adding dialup passwords to your modem lines is such a simple proc-ess that I recommend it for anyone who uses inbound modems. In this article, we're assuming that you already have incoming modem lines installed and tested. You need to take only three additional steps to add dialup passwords:

• Create the /etc/dialups file, specifying the devices that
  require dialup passwords.
• Create the /etc/d_passwd file, specifying the password for each login shell.
• Test your configuration.

Once you've configured dialup passwords, the new dial-in login process works as follows: When a user attempts to log in to the computer, Solaris first issues a prompt for the username and password, just like normal. Then, if the /etc/dialups file lists the port, the login program looks in the /etc/d_passwd file for the shell that the user is attempting to use. Solaris then prompts the user for the dialup password for the shell before granting access.

Creating the /etc/dialups file

The first file you must create is /etc/dialups, which specifies for which ports you want the extra password enabled. You create this file by specifying the incoming ports, one per line, that you want secured with a dialup password.

For instance, let's assume you have a computer with three modems that have dial-in access. These modems are connected to ports /dev/term/b, /dev/term/c, and /dev/term/d. In this case, you should create your /etc/dialups file to contain the following three lines:

/dev/term/b
/dev/term/c
/dev/term/d

For security purposes, both the user and group ownership should be set to root. In addition, only root should have read or write access to it. Assuming that you're logged in as the root user, you can use these commands to finish setting up
the file:

# chown root /etc/dialups
# chgrp root /etc/dialups
# chmod 600 /etc/dialups

Creating the /etc/d_passwd file

The /etc/dialups file we just created tells Solaris which ports we want to secure. Next, we must set up the dialup passwords. Rather than giving each user another password, you must associate the dialup passwords with the login shell. Each login shell may have its own dialup password.

Each line in the /etc/d_passwd file contains two fields terminated by a colon (:). The first field specifies the login shell to protect, such as /bin/sh or /bin/ksh. The second field contains the 13-character encrypted password for the login shell. The encrypted password field in /etc/d_passwd uses the same format as the one in /etc/shadow.

If you don't specify a password for a particular login shell, it will use the same password you've defined for /usr/bin/sh. If you haven't specified a password for /usr/bin/sh, then the system won't prompt you for a dialup password.

For security reasons, you should always specify a password for the shell /usr/bin/sh. You want to do this because if you add a new shell to your system, such as tcsh or bash, you may forget to add an entry for it in the /etc/d_passwd file. If that happens when you don't have an entry for /usr/bin/sh, anyone using the new shell will be able to log in without using the dialup password!TRICK: If you want to use the same dialup password for all shells, you can just set up the entry for /usr/bin/sh in /etc/d_passwd. If, on the other hand, you want to use different passwords for different shells, you should add the entry

/usr/bin/sh:*LK*

to your /etc/d_passwd file. This prevents anyone from logging in remotely with any program not explicitly mentioned in /etc/d_passwd. However, it also prevents you from specifying /usr/bin/sh as the login shell for any remote user. You can still allow a remote user to use the Bourne shell by using admintool and specifying /bin/sh as the shell, and adding an entry for /bin/sh in
/etc/d_passwd. This way, you get security as the default behavior and can still use the Bourne shell for remote access.

The final /etc/d_passwd file that provides protection for the Bourne, Korn, and C shells looks something like this:

/usr/bin/sh:*LK*
/bin/sh:i4lUy7yLcj4Ru:
/usr/bin/ksh:Bt1Mc0.ejy.XN:
/usr/bin/csh:d2I163trYS3ab:

Now let's step through the process of generating a password for the /usr/bin/ksh entry. First, we must create an encrypted password. Unfortunately, there's no simple process in Solaris to create a password for a shell. However, since the
encrypted password for the /etc/d_passwd file uses the same format as those in the /etc/shadow file, we can create a temporary user account, set its password, and then copy its encrypted password from the
/etc/shadow file into the /etc/d_passwd file.

To do so, you need to be the root user. First, create a temporary account named tempuser:

# useradd tempuser

Next, set the password for the tempuser account to the dialup password you want for the shell /usr/bin/ksh. In this case, we're going to use Mark16:

# passwd tempuser
New password: Mark16
Re-enter new password: Mark16

Now find the encrypted password entry for tempuser in the /etc/shadow file, using the command

# grep tempuser /etc/shadow
tempuser:k8AqzGjr6amOY:9762::::::

The second field in the line is the encrypted form of the password Mark16; in this case, it's k8AqzGjr6amOY. Now, edit the /etc/d_passwd file and create the line

/usr/bin/ksh:k8AqzGjr6amOY:

Don't forget to follow the encrypted password with a colon!

You can create entries for other login shells, such as the Bourne or C shells, by following this same procedure. For those shells, use the tempuser account to generate your encrypted passwords. When you're finished using the tempuser account, delete it:

# userdel tempuser

Once you've created the /etc/d_passwd file, give it the same ownership and permissions as the /etc/dialups file:

# chown root /etc/d_passwd
# chgrp root /etc/d_passwd
# chmod 600 /etc/d_passwd

Testing your dialup password

The final step in the configuration process is to test your dial-in modem lines. You can do so by dialing in to your Solaris computer and logging in. If everything is set up properly, your login dialog will involve three prompts, shown below. Please note that, for clarity, we've shown the passwords, even though they don't appear on the terminal:

login: marco
Password: zort!poit
Dialup Password: Mark16
Last login: Mon Sep 23 13:09:16 on term/b

* * *

You're prompted for the Dialup password only if you get the user name and account password correct. This way, you don't have to wonder which password you may have typed incorrectly: If you get your user password wrong, you won't get the Dialup password prompt. However, this tells a potential hacker when he or she has guessed the password for your account. To help thwart these hackers, Solaris pauses a second before telling you whether the Dialup password is right (by logging you in) or not. This time delay places an upper limit on the speed a hacker may guess passwords. In addition, after a few failed login attempts, Solaris terminates the connection, forcing a hacker to dial up the computer again, consuming more valuable time.

Once you enter the proper dialup password for your login shell, your login process will proceed as usual. When you pass this login test, your configuration process will be complete. When you test your system, be sure to try each different login shell, as well as one that's not in /etc/d_passwd, to make sure you're happy with the behavior.

More security on modem lines

If you want to make your computer system even more secure, you can take other approaches, such as using cron to change the /etc/d_passwd file on a periodic basis, for instance on shift changes. You can do this by creating a series of files with the /etc/d_passwd file format, each containing different passwords. Then you can use cron to replace the /etc/d_passwd file with one of these files each time period. The important part for you and your users is to remember when each password is valid.

You can also protect your dial-in modem lines with third-party hardware devices. These devices connect to your telephone line, between the wall jack and the modem. When a remote user dials your modem's phone number, this device picks up the phone line immediately and simulates a telephone ring.

This simulated ring continues unless the remote user has included a security code in the modem dialup string. For instance, if a user is calling the phone number 555-1212, and has a security device with a code of 1234, a proper dial-in string for the remote modem might be

atdt5551212,,,1234

You could interpret this dial-in string as, "Call the phone number 555-1212, wait six seconds, then issue the code 1234." When the user includes this security code, it triggers the third-party device, allowing the user to get through this device and into your modem. If the user hasn't included a security code, all that person will hear is a remote ringing telephone. I've found this to be an outstanding security measure.

You can also purchase third-party soft-ware that will add the best security possible: callbacks. These give each user a prearranged number to dial in from. Once a user calls in and identifies himself, Solaris then hangs up on the user and calls back at the prearranged number. So even if a hacker figures out the identification of a valid user on the system, he can't log in remotely unless he's at the correct phone number! The big headache for a callback system is managing phone numbers for users that move frequently, such as sales staff. v

Alvin J. Alexander is an independent consultant specializing in UNIX and the Internet. He has worked on UNIX networks to support the space shuttle, international clients, and various Internet service providers. He has provided UNIX and Internet training to over 400 clients in the last three years.

[The Cobb Group Home Page]

Copyright (c) 1996 The Cobb Group, a division of Ziff-Davis Publishing Company. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Ziff-Davis Publishing Company is prohibited. The Cobb Group and The Cobb Group logo are trademarks of Ziff-Davis Publishing Company.